This application claims the priority of German patent document 199 09 157.9, filed Mar. 2, 1999, the disclosure of which is expressly incorporated by reference herein.
The invention relates to a distributed vehicle information processing and vehicle control system, having at least two system parts as network nodes which communicate via a data transmission network, and at least one of which is arranged on the vehicle side.
Overall, such systems are used for carrying out vehicle-related applications of widely varying types, for example in conjunction with user interfaces, internal and external communication, application support and with the actual applications and services themselves. The latter includes, for example, actuation of vehicle units, evaluation of vehicle sensor information and general services such as navigation, diagnosis, anti-theft devices and data interchange with remote network nodes, for example via the Internet.
Modern vehicle systems are distinguished by a data processing element that is becoming ever larger; that is to say telematics applications are becoming increasingly important. For example, breakdown services and dynamic navigation services as well as Internet-based applications demand the implementation of distributed systems, in which the vehicle is no longer regarded as an isolated individual system, but as an active node in a distributed data communications system, preferably with a worldwide range. System applications implemented aboard the vehicle will in this case in general carry out not only client functions but also server functions.
The layering of functionalities that are required for a vehicle system has already been proposed for a vehicle communications system disclosed in German Patent Document DE 196 25 002 A1, which uses adaptive application control, and allows a certain amount of variability in the assignment of the applications to various interfaces and appliance units on the vehicle side.
In the field of general data processing, a component-based system design has recently been proposed as an alternative to central system architectures. See, for example, the Journal article D. Kiely, xe2x80x9cAre Componentsxe2x80x94The Future of Software?xe2x80x9d, IEEE Computer Magazine, page 10, February 1998. In this case, the function to be provided by the overall system is broken down into individual functional units (xe2x80x9ccomponentsxe2x80x9d), which then provide the overall desired function by suitable linking and communication with one another. Such breakdown into components on the one hand simplifies their reuse and the design of complex systems from these components, and on the other hand simplifies the production of robust components themselves (since they need be equipped with only a limited, clear functional scope). The components are characterized by their external identical architecture, which makes it possible to link them to one another in a simple manner, such that the function provided by a particular component may initially be viewed independently of this architecture.
The explosive growth in the Internet and the Worldwide Web has led to distributed systems becoming increasingly important. To simplify the implementation of such systems, and to allow component-based systems to be provided, an increasing number of distributed object models have been established. The system developers are also making ever greater use of Internet-oriented solutions for these object models and are implementing them, for example, using Java RMI or xe2x80x9cJava Beansxe2x80x9d. See the corresponding Internet information from Sun Microsystems with DCOM from Microsoft; see also, the publications T. Albertson, xe2x80x9cBest Practices in Distributed Object Application Development: RMI, CORBA and DCOM, February 1998, Internet page xe2x80x9chttp://developer.com/news/techfocus/022398_distl.htmxe2x80x9d and P. E. Chung et al., xe2x80x9cDCOM and CORBA Side by Side, Step by Step, and Layer by Layer, September 1997, Internet page xe2x80x9chttp://www.cs.wustl.edu/≈schmitt/submit/Paper.htmlxe2x80x9d, or, on the basis of CORBA, see also A. Vogel, K. Duddy, xe2x80x9cJava Programming with CORBAxe2x80x9d, John Wiley and Sons, 1997.
As is evident from the cited literature, the trend towards object-oriented component models can be explained by the following advantages: first, by the capability for reuse of existing algorithms and software, and for xe2x80x9crapid prototypingxe2x80x9d of applications by xe2x80x9cplug-and-playxe2x80x9d interaction of the components; second, mutually independent development and implementation of components; third efficient code maintenance including the systematic distribution of updates; and fourth xe2x80x9clightweightxe2x80x9d and xe2x80x9cthin clientsxe2x80x9d implementations, which communicate with infrastructure-based systems, which can be localized there at various points.
One of the characteristic features of such components is that they follow a standard architecture specification, which makes it easier to join them together to form an overall system. In this case, this architecture in principle has nothing to do with the actual function of the component. In fact, it defines how the components interact with one another, but not how they xe2x80x9cconversexe2x80x9d. This characterization is independent of whether the specific component is in the form of software or hardware.
The trend towards component models is evident in the increasing importance of technologies which support distributed component systems, such as xe2x80x9cJava Remote Method Invocation (RMI)xe2x80x9d as the basis for the JavaBeans components xe2x80x9cCommon Object Request Broker Architecture (CORBA)xe2x80x9d and xe2x80x9cDistributed Component Object Model (DCOM)xe2x80x9d from Microsoft for implementation of ActiveX. All these models use the client/server approach.
In the past, when vehicles have been delivered to the customer at the end of production, their functionality in terms of services that can be carried out has been relatively greatly fixed. In the future, however, more and more services will be used in vehicles, in the same way that they are also being used in the office and business worlds, even though they still scarcely exist at all at the moment when the vehicle is manufactured. In future, the customer will therefore wish to be able to reequip the vehicle with corresponding new services, for the life of the vehicle. If the reequipment is done by additionally downloading software into the vehicle, then the memory space required for this purpose in the vehicle will at some time no longer be adequate. On the other hand, reequipment additional hardware is comparatively costly and susceptible to faults, and in most cases involves the vehicle being left in a workshop.
There is therefore a requirement for systems which can relatively easily be reequipped with additional functions which are provided, for example, as software modules, so that no hardware modification is required. Furthermore, it is desirable to be able to match the system optimally to changing requirements and conditions by dynamic movement, preferably of software modules, to or from the system part on the vehicle side, for the life of the vehicle. This applies, for example, to changing conditions for wireless communication. If only narrowband communication is available, as little communication as possible should be carried out and as much of the necessary software as possible should be accommodated in the vehicle. On the other hand, if a communications link with a high transmission capacity is available, certain operating software can more advantageously be accommodated in a system part outside the vehicle, in order to allow the generally greater computation capacities there to be utilized.
One object of the present invention is to provide a vehicle information processing and vehicle control system of the type mentioned initially, whose structure for carrying out various vehicle-related applications is designed comparatively flexibly, so that reequipping with further functions is possible at relatively low cost. Also, the precondition is provided to allow the required applications to be carried out such that they are distributed variably, dynamically and flexibly between the system parts, and such that the vehicle can be integrated as an active network node in a data network which may be worldwide.
These and other objects and advantages are achieved by the distributed vehicle information processing and vehicle control system according to the invention, whose system parts have a component-based construction, being composed of different components which communicate with one another in order to carry out the various desired application functions. Each of these components, which are defined in this way and are preferably in the form of software on the one hand, has a function-calling interface via which the function carried out by the component can be called up by all the active nodes in the network, and a configuration interface, via which its configuration can be defined. Thus, it can be varied, by means of a configuration manager unit provided for this purpose.
To this end, the configuration manager unit receives knowledge about the components that are present in the system, and configures the respective component, via its configuration interface, depending on what other components are present. In consequence, this configuration manager unit allows a component which has been newly fitted in a system part (irrespective of whether this is by reequipment of the system with the same system part or by movement from another system part) to be xe2x80x9cconfiguredxe2x80x9d such that it can communicate optimally with the other components that are present.
Matching of the new components to the relevant system part may possibly also involve a modification of the configuration of one or more of those components which were already present. This design allows the vehicle-related system to be equipped with a general data processing platform, which allows flexible reloading of further executable vehicle-related applications at any time during the life of the vehicle, while allowing optimized-cost reaction by service implementations to variable external conditions.
In one embodiment of the invention, a component loader is provided for the respective system part (also referred to as a xe2x80x9cbathtubxe2x80x9d in general computer processing), which accommodates the respective components. The latter communicate via the component loader with an operating system in the system part to which, on the other hand, various external appliance units are coupled, depending on the system part.
In another embodiment of the invention, a function-based hierarchy of the components is provided in vehicle-component-related components or xe2x80x9cinterfacexe2x80x9d components, which are closely based on the existing hardware, vehicle appliance units and, for example, provide access to hardware interfaces for communications appliances or the display and control appliances of a user interface. Aggregation components offer services which aggregate raw information from the vehicle-component-related components, and in higher-level application components represent the actual services and have access not only to the aggregation components but also to an intermediate layer and to the vehicle-component-related components and user-interface components.
According to another feature of the invention, means are provided for dynamically moving one or more of the components between the involved system parts during the system life, and thus, in particular, at any desired times throughout the entire life of the vehicle. These means for moving components make use of the fact that the components are provided with a configuration interface and are xe2x80x9cconfigurablexe2x80x9d via this interface. Thus, they can be varied to match a new component environment of a different system part. In consequence, a respective component can, for example, be placed in one system part for certain times and in another system part for other times, depending on the changing external conditions, such as the available transmission capacity of the network communication path. Those components which are not closely related to vehicle-side hardware appliance units are particularly suitable for such movement.
Finally, according to another feature of the invention, communication between application-related components is direct, and thus the components must know the interfaces of those components which they use. Alternatively, communication takes place via a respective, jointly used data-maintenance component, to which the application components involved write new information; and information that has newly been written there can be read by other involved components. In this case, the application components do not need to know the interfaces of the other components, but it is necessary to agree what contents are written to the data-maintenance component.
Other objects, advantages and novel features of the present invention will become apparent from the following detailed description of the invention when considered in conjunction with the accompanying drawings.